1. Field of the Invention
The present invention generally relates to provision of security and access authorization checking in computer systems and, more particularly, to the provision of security and limitation of access to data and facilities of data processing and network service applications such as interactive user programs, routing applications and data storage applications.
2. Description of the Prior Art
Data processors have proliferated in recent years as their capabilities and economic accessibility have increased. At the same time, the demand for applications programs to increase those capabilities and to exploit increased available processing power of processors for an increasingly wider range of uses has resulted in a similar proliferation in applications programs. Recent advances in interconnectivity have allowed sharing of both hardware (e.g. printers and memory, including distributed file systems) and software (e.g. data and applications) resources between processors over a network. Because of interconnectivity of processors and sharing or distribution of resources, physical security of a particular processor which is interconnected with any other processor provides little security for data or applications thereon.
Historically, information security has been addressed at the operating system and network levels; tending to locate computer security into a small kernel at the lowest level of the operating system and network protocols in an effort to minimize the amount of security-related code required. However, such an approach imposes security constraints onto otherwise untrusted applications and is inflexible and not easily adapted to differing security requirements such as differentiating levels of authorization for different categories of users.
To obtain greater flexibility where desired, current access authorization arrangements have generally been applied at the application program level or, for networks, at the "middleware" level (services located above network protocols but below applications). However, middleware level system security assumes a discrete and integral network for application of a singular security system under the control of a system administrator (but which does not preclude provision of further security at the data, file or application level). Application level security and security for data which may be controlled under that application (e.g. so-called fine grain labelling at the level of a file or specific information such as a sentence, paragraph or particular numerical data within a file) is generally implemented in a manner which is specific, if not unique, to each application.
The addition of programming to implement application level or middleware security may comprise a significant fraction of the software of the application or middleware and is time-consuming and therefore expensive to develop. Further, since it is desirable that different applications be able to access and process information from other applications (at least to avoid the need for additional data entry or manual control of data transfer), issues of compatibility of security arrangements (e.g. logon or identification format which vary widely between known security arrangements) must be assured. Further, if data is duplicated for processing by different applications, issues of data integrity can arise since data could be updated in one application while obsolete data remained available from another.
Additionally, in data processing systems capable of handling large databases and storage of large numbers of files which are accessed by a large population of users, it is common to provide or limit access to documents or files by category of document or portion thereof in a hierarchy of access levels (e.g. "top secret" "secret", "confidential" and the like) and to similarly categorize users by access rights in accordance with corresponding hierarchical levels of access authorization or clearance, referred to as classification-based policies. Such systems are generally used by the military.
It is also common to limit access by information content category (e.g. confidential, internal use only, proprietary technical information, personal and the like) and to limit access based on some activity, employment or need-to-know based criteria (e.g. system administrator, managers, engineers, programmers and the like), which are referred to as role-based policies. Classification-based policies (and, in general, role-based policies) are collectively referred to as multi-level security or mandatory access control (MAC) policies.
Alternatively, storage can be partitioned (e.g. into mini-disks, virtual partitions or the like) and access to partitions and groups of partitions granted to individual users or groups of users (e.g. by use of aliases) in accordance with access lists or similar mechanisms, referred to collectively as discretionary access control (DAC) policies. Role-based policies may also be implemented by partitioning in a DAC manner based on mini-disks, subject matter categories or the like. However, mandatory and discretionary access control policies are not easily reconciled or hybridized to provide a mixture of functions and, while they can be used together by requiring that access be granted under each system individually, only one or the other is usually provided and then rigidly enforced across all applications. That is, the security policy and the enforcement policy are generally bound together. Further, discretionary access control arrangements based on virtual partitions of storage is generally incompatible with fine-grained security.
Accordingly, so-called trusted applications have been developed to provide fine-grained security as well as by categories of documents and users and partitioned storage access authorizations, as may be desired, in applications and network services. A trusted application is an application which supports the labelling of specific data (e.g. a file or portion of text or range of data within the file consistent with requirements for fine-grained security) with security attributes (e.g. "secret", "confidential", "internal use only", "personal" and the like) and can support enforcement of desired security policies (e.g. MAC, DAC, role-based policies and the like). The term "trusted applications", for purposes of this disclosure, will be considered to also include trusted network and application services having similar capabilities in regard to network communications, routing, shared resources and the like.
Heretofore, trusted applications were developed for specific customers with specific security policies which might differ between applications. Therefore, to accommodate a wide variety of security policies there was little opportunity to re-use existing software in new environments even though trusted applications may have been costly to produce. Accordingly, each new trusted application has required a significant investment in time and cost to implement desired security arrangements and there has been virtually no assurance of compatibility of security arrangements between applications.
In summary, there has been no system which provides separation of security policy from security enforcement together with fine-grained securing of objects and access control except by customized, application-specific, programming which largely precludes re-use of code in development of new applications. Further, in general, discretionary access control systems and mandatory access control arrangements, while usable together, cannot be reconciled and, once established for an application or system, neither can be modified or tailored to meet the requirements of the other without rewriting substantial amounts of code which may be distributed throughout the application.
So-called object oriented programming has become known in recent years. Object oriented programming is not so much a new form of programming or language (although some new programming languages and modifications of existing languages have been introduced to facilitate it) as it is a new, modular view of the construction or architecture of programs in which the system embodied by the program is decomposed into a collection of communicating objects.
Key concepts in object oriented programming which are of importance to the present invention are encapsulation, classification and inheritance. Encapsulation reflects hiding of the internal mechanisms of an object from the users (which may be other objects) of an object as well as other parts of the system to avoid the need for system-wide changes when any object is modified. Classification characterizes the behavior of a set of objects. Inheritance is a property which allows an object or a class of objects to extend (or, conversely, specialize) the behavior of an existing class of objects. Classes of objects are arranged into a hierarchy wherein a class lower in the hierarchy inherits the interface and behavior of its parent class. Conversely, a higher class is a generalization of its descendants, both as to the characteristics and behaviors or methodologies they embody.
In the object oriented approach, a distinction is made between abstract and concrete classes of objects. A concrete class can instantiate objects (e.g. objects are instances of members of a concrete class) whereas an abstract class is a generalization insufficiently specific to support object instances. For example, in the hierarchy vehicle-car-sedan, a class "car" is a generalization of all models of cars and thus the class "car" which represents mutually exclusive models of cars (e.g. coupes, roadsters, sedans, station wagons) as subclass instances but specific cars cannot be instantiated (since mutual exclusivity prevents generalization of attributes which are significant to the decomposition). However, a subclass "sedans" inherits behavior of parent class "car" and its parent class, "vehicle", and supports instances of specific models of "cars" which are "sedans". More generally, in a hierarchical tree structure, internal nodes of the tree would usually be abstract classes and "leaf nodes" would be concrete classes. Due to inheritance, abstract classes may be viewed as templates for concrete classes.
An object oriented framework comprises a class library containing both abstract and concrete classes. The core of a framework is a set of abstract classes that define a general set of concepts. The framework thus comprises high-level abstractions that are refined in further abstract and concrete classes through inheritance. The concept of an object oriented framework and the library it embodies is in marked contrast to traditional program libraries which contain more or less generalized low-level modules which are called by application programs. Thus, the primary virtue of object oriented program design is that it permits maximum re-use of existing code and data, through inheritance and encapsulation, and allows the programmer to develop routines by developing abstract and concrete subclasses based on the concepts and behaviors (e.g. default methods) embodied in abstract classes organized in the framework to support specific desired behaviors or implement specific desired policies for operation of the system.
A further important benefit of an object oriented framework is that the programmer often may not need particular expertise in regard to the functions to which the framework is directed since, to a greater or lesser degree, that expertise is embodied in the framework itself. The developer then need only develop objects specific to the application to be controlled by the framework and which will inherit properties and behaviors of classes within the framework. The inherited properties and behaviors thus need not be defined, formulated or implemented by the developer but only selected by development of application-specific objects to inherit the desired properties and behaviors.
By the same token, however, development of a framework is by no means trivial since the definition of classes and subclasses and their organization (e.g. by definition of attributes and relationships, sometimes referred to as "has" and "uses" relationships) must embody particular expertise to the same degree that a subsequent program developer using the framework can be relieved of it. Additionally, the definition of the hierarchy of classes and subclasses and the articulation of the framework must accommodate abstract classes comprehending all potential variations and specific behaviors which can be produced therefrom (e.g. inherited by instantiated objects).
Further, object oriented programming does not, in and of itself, reconcile conflicting requirements of behavior of systems. On the contrary, the hierarchical nature of a framework or any object oriented program design theoretically implies that generalization must be possible. Where severe conflicts and mutual exclusivities exist, the essential potential for generalization is usually lacking. Therefore, the ability to impose fine-grained labelling together with mandatory or discretionary access control must generally be custom built for each application.